Field of the Invention
The present invention relates to a computer program product, system, and method for copy source to target management in data storage systems.
Description of Related Art
Data storage systems, particularly at the enterprise level, are usually designed to provide a high level of redundancy to reduce the risk of data loss in the event of failure of a component of the data storage system. Thus, multiple copies of data are frequently stored on multiple systems which may be geographically dispersed. Accordingly, data from a host to be stored in the data storage system is typically directed to a primary device of a primary data storage system at a local site and then replicated to one or more secondary devices of secondary data storage systems which may be geographically remote systems from the primary data storage system. One primary device can have multiple secondary relationships in which data directed to a primary device is replicated to multiple secondary devices.
A storage controller may control a plurality of storage devices that may include hard disks, tapes, etc. A cache may also be maintained by the storage controller, where the cache may comprise a high speed storage that is accessible more quickly in comparison to certain other storage devices, such as, hard disks, tapes, etc. However, the total amount of storage capacity of the cache may be relatively small by comparison to the storage capacity of certain other storage devices, such as, hard disks, etc., that are controlled by the storage controller. The cache may be comprised of one or more of random access memory (RAM), non-volatile storage device (NVS), read cache, write cache, etc., that may interoperate with each other in different ways. The NVS may be comprised of a battery backed-up random access memory and may allow write operations to be performed at a high speed. The storage controller may manage Input/Output (I/O) requests from networked hosts to the plurality of storage devices.
Caching techniques implemented by the storage controller assist in hiding input/output (I/O) latency by reducing the effective time required to read data from or write data to a lower speed memory or storage device. Thus, the cache is used for rapid access to data staged from external storage to service read data access requests, and to provide buffering of modified data. Write requests are written to the cache and then written (i.e., destaged) to the external storage devices. To guarantee continued low latency for writes, the data in the NVS may have to be drained, that is destaged, so as to ensure that there is always some empty space for incoming writes.
A Task Control Block (TCB) is a task control data structure in the operating system kernel containing the information needed to manage a particular process. Storage controllers may move information to and from storage devices, and to and from the cache (including the NVS) by using TCBs to manage the movement of data. When a write request issues from a host computer to a storage controller, a TCB may be allocated from the operating system code. The TCB is used to maintain information about the write process from beginning to end as data to be written is passed from the host computer through the cache to the storage devices. If the cache is full, the TCB may be queued until existing data in the cache can be destaged (i.e., written to storage devices), in order to free up space. The destage operations may involve the moving of information from cache to storage such as Redundant Array of Independent Disks (RAID) storage and destage TCBs may be allocated for performing the destage operations.
TCBs may be classified on the basis of the task being controlled by the particular TCB. For example, a “background” TCB is a TCB that controls an operation which is not directly related to a host input/output operation. Thus, one example of a background TCB is a TCB which controls a destage operation as a background operation not required as part of a particular host I/O operation. Another example of a background TCB is a TCB which controls a prestage of tracks from storage to cache in which the prestage operation is being performed as a background operation not required as part of a particular host I/O operation.
Another type of TCB is a “foreground” TCB that controls an operation which is typically directly related to a host input/output operation. For example, a foreground TCB may be allocated to perform a destage or stage operation on behalf of a host I/O operation. Thus, a cache miss on a host read typically causes a stage operation controlled by a foreground TCB, to stage one or more tracks from storage to cache to satisfy the host read operation.
Storage controllers frequently employ a safe data commit process which scans a cache directory for modified (often referred to as “dirty”) data to be destaged to secondary storage. Such a scan of the cache directory may be initiated on a periodic basis, such as on the hour, for example.
In data replication systems, data is typically maintained in volume pairs, comprising a primary volume in a primary storage device and a corresponding secondary volume in a secondary storage device that includes an identical copy of the data maintained in the primary volume. The primary and secondary volumes are identified by a copy relationship in which the data of the primary volume, also referred to as the source volume, is copied to the secondary volume, also referred to as the target volume. Primary and secondary storage controllers may be used to control access to the primary and secondary storage devices.
A near instantaneous copy of a set of tracks may be generated using a point-in-time snap copy function such as the IBM® FlashCopy function, for example, which establishes a point-in-time copy relationship between a set of source tracks and a set of target tracks in a storage controller. The set of tracks of the copy relationship may comprise full volume or a logical unit (LUN) or parts of a volume, for example. Thus, if the set of tracks is a full volume, for example, the point-in-time snap copy function creates a “snapshot” of the contents of a source volume as of a particular time in a target volume which may be referred to as the point-in-time snap copy volume or simply point-in-time copy volume. One version of a point-in-time snap copy function transfers the contents of the point-in-time copy source volume to the point-in-time copy target volume in a background copy operation.
Any read operations directed to a track of the point-in-time copy target volume which has not yet received the contents of the corresponding track of the source volume, are redirected to obtain the contents of that track from the source volume. Accordingly, the contents of a point-in-time copy target volume are immediately available albeit indirectly, before any tracks have actually been transferred to the target volume. Conversely, if the host directs an update to a track of the source volume before the contents of that track have been transferred to the point-in-time copy target volume, the contents of the track of the source volume are transferred to the point-in-time copy target volume before the update is permitted to overwrite the contents of that track of the source volume.
Another version of a point-in-time snap copy function omits the background copy operation. Thus, the contents of the source volume are not transferred to the point-in-time copy volume in a background copy operation. Accordingly, any read operations directed to a track of the point-in-time copy target volume are usually redirected to obtain the contents of that track from the source volume. However, if the host directs an update to a track of the source volume, the unmodified contents of that track of the source volume are transferred to the point-in-time copy target volume before the update is permitted to overwrite the original, unmodified contents of that track of the source volume. Doing such a copy operation at the time of write is known as a “Copy on Write”.
Data may be also copied from source to target when there is a destage to the source for data written to the cache after the point-in-time copy relationship was established, and is typically referred to as “Copy On destage”. Known copy on destage operations can consume significant system resources. More specifically, the copy on destage operation first stages to cache old, unmodified data from the source of the point-in-time copy relationship and then destages from cache that old, unmodified data to the target of the point-in-time copy relationship. The destage of new, modified data from the cache to the source is then allowed to overwrite the old, unmodified day on the source. It is appreciated that such known copy on destage operations for point-in-time copy relationships can significantly slow destage operations to the source.
For sequential writes directed to the source of a point-in-time copy relationship, a “Copy On Destage” operation typically reads the old, unmodified data in a full stride of tracks from source, stages the stride of data to cache, and then destages the data of those tracks to the target of the point-in-time copy relationship. A stride is a set of tracks, typically sequential tracks, having well defined beginning and ending boundaries. Parity data such as RAID (Redundant Array of Independent Disks) parity data, for example, is computed based upon the data to be stored on the tracks within those boundaries and the parity data for the stride of tracks is also stored within the stride boundaries. Hence, read and write operations which are aligned with the boundaries of one or more strides, facilitate efficiency since read (decoding) and write (encoding) operations may be completed for stride parity data on a stride by stride basis.
Thus copy on destage operations are facilitated if the source and target strides are aligned. However, if the source and target strides do not align then destages on the target typically will not be stride-aligned with stride boundaries of the target notwithstanding that read operations from the source may be stride-aligned with the stride boundaries of the source. In various systems, it is difficult to create a configuration where source and target strides are aligned. Hence, sequential I/O performance may be adversely impacted when there are point-in-time copy relationships in the storage controlled by a storage controller.